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Abstract:  We  have  implemented  in  simulation  a  prototype  language  for  the  Connection  Machine  called 
CL1.  CL1  is  an  extrapolation  of  serial  machine  programming  language  technology:  in  CL1  one  programs  the 
individual  processors  to  perform  local  computations  and  talk  to  the  communications  network.  We  present 
details  of  the  largest  of  our  experiments  with  CL1,  an  interpreter  for  Scheme  (a  dialect  of  Lisp)  that  allows  a 
large  number  of  different  Scheme  programs  to  be  run  in  parallel  on  the  otherwise  SIMD  Connection 
Machine.  Our  aim  was  not  to  propose  Scheme  as  a  language  for  Connection  Machine  programming,  but  to 
gain  experience  using  CL1  to  implement  an  interesting  and  familar  algorithm.  Consideration  of  the 
difficulties  we  encountered  led  us  to  the  conclusion  that  CL1  programs  do  not  capture  enough  of  the  causal 
structure  of  the  processes  they  describe.  Starting  from  this  observation,  we  have  designed  a  successor 
language  called  CGL  (for  Connection  Graph  Language). 
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Introduction 


We  have  implemented  a  prototype  language  for  the  Connection  Machine  (henceforth  CM)  [11]  called  CL1 
|4).  CL1  extrapolates  serial  machine  programming  language  technology  to  the  purposes  of  massively  parallel 
machines.  We  observed  that  the  individual  CM  processing  elements  could  be  modeled  by  a  compiler  in  much 
the  same  way  as  a  serial  machine  compiler  models  the  target  machine's  CPU  and  registers.  A  CL1  program 
talks  to  the  CM's  communications  network  in  much  the  same  was  as  a  conventional  machine  talks  to  its 
memory. 

By  experimenting  with  this  language,  we  hoped  to  expose  its  inadequacies  and  learn  from  them.  We 
present  here  the  details  of  our  largest  experiment,  an  interpreter  for  Scheme  [14J,  a  dialect  of  Lisp.  Our  aim 
was  not  to  propose  Scheme  as  a  language  for  CM  programming,  but  to  gain  experience  using  CL1  to 
implement  an  interesting  and  familar  algorithm. 

Consideration  of  the  difficulties  we  encountered  has  led  us  to  the  conclusion  that  CL1  programs  do  not 
capture  enough  of  the  causal  structure  of  the  processes  they  describe.  Starting  from  this  observation,  we  have 
designed  a  successor  language  called  CGL  (for  Connection  Graph  Language),  which  we  will  describe  in  [5]. 

The  Connection  Machine 

The  CM  is  a  massively  parallel  computer  now  being  designed  and  built  at  the  MIT  Artificial  Intelligence 
Laboratory.  It  consists  of  a  large  array  of  identical  small  processor  cells  connected  by  a  communications 
network.  The  cells  combine  features  of  both  the  processors  and  memory  words  of  traditional  architectures. 
By  distributing  processing  power  across  a  large  address  space,  the  CM  architecture  avoids  the  bottleneck 
between  processor  and  memory  characteristic  of  conventional  architectures  [3]. 

Like  the  memory  of  a  conventional  machine,  the  CM  is  intended  to  have  enough  cells  that  the  expense  of 
allocating  a  new  cell  should  be  comparable  to  that  of  allocating  a  new  word  of  memory  on  a  conventional 
machine.  The  current  design  includes  one  million  cells  ••  a  20-bit  address  space. 

Like  the  CPU  of  a  conventional  machine,  each  cell  has  a  few  hundred  bits  of  state.  The  cells  do  not  have 
any  local  program  storage  or  program  counter.  Instead,  instructions  arc  broadcast  by  the  host  machine  to  all 
cells  at  once  over  a  common  instruction  bus.  The  CM  is  thus  a  SIMD  (single-instruction,  multiple-data) 
architecture,  although  the  SIMD  nature  of  the  machine  docs  not  play  any  role  in  this  paper  (except  in  the 
section  about  efficiency  considerations).  Each  cell  has  a  serial  ALU  capable  of  executing  any  of  a  small 
number  of  operations.  The  programmer  can  specify  that  only  a  certain  subset  of  the  cells  in  the  machine 
should  execute  a  given  instruction  by  making  execution  of  that  instruction  conditional  on  the  value  of  a  status 
flag  in  each  cell. 

The  cells  are  connected  by  a  communications  network.  If  cell  A  has  the  address  of  cell  B  in  its  local 
memory,  then  A  can  use  the  network  to  transmit  a  "message"  of  any  length  to  B.  Neither  cell  need  know 
anything  about  the  structure  of  the  network  in-between.  This  network's  transmission  protocol  has  been  kept 
simple  because  of  the  sobering  observation  that  one  pays  for  any  feature  one  adds  to  the  cells  a  million  times 
over.  The  hardware  provides  no  mechanisms  for  message  arbitration:  there  is  no  hardware  support  for 
queueing,  for  example.  Because  of  this.  CM  programming  languages  must  provide  more  useful  message 


sending  abstractions  built  on  llic  primitive  foundation  provided  by  the  hardware. 

Programming  a  Connection  Machine 

The  CM  was  originally  designed  as  a  peripheral  for  storing  and  operating  on  semantic  network  databases. 
Since  the  CM's  design  was  more-or-less  finalized,  we  have  been  able  to  experiment  with  programming  it  (in 
microcode)  for  other  applications.  Here  arc  the  basics  t»f  CM  programming  as  we  now  understand  them;  see 
|b|  for  more  details. 

In  die  CM.  as  in  a  conventional  machine,  one  builds  data  structures  by  allocating  cells  and  connecting 
diem  together  by  storing  addresses  of  cells  --  "pointers"  --  in  the  memory  of  other  cells.  Since  a  pointer  can 
only  be  used  as  an  instruction  to  the  communications  network  for  delivering  a  message,  the  pattern  of  pointers 
in  a  CM  might  best  be  thought  of  as  a  virtual  communications  network.  Ibc  ability  to  pass  pointers  from  cell 
to  cell  as  data  can  thus  be  thought  of  as  die  ability  to  dynamically  reconfigure  the  network  to  suit  the  occasion. 
'Ibis  ability  ;o  form  new  "connections"  through  the  communications  network,  under  software  control,  gives 
die  Connection  Machine  its  name. 

Cells  in  the  CM.  like  words  of  a  conventional  machine’s  memory,  will  typically  be  used  for  a  number  of 
different  puiposcs  in  any  particular  computation.  Some  cells  might  be  linked  into  a  binary  tree  to  represent  a 
set.  Others  might  act  as  record  structures  to  represent  objects  with  components.  A  space-ship  might  have  a 
position,  a  velocity,  and  an  owner. 

Ibc  manipulations  performed  by  a  cell  on  the  data  in  its  local  storage  closely  resemble  those  of  a 
conventional  general- register  computer  on  die  data  kept  in  its  register  set.  Calculations  arc  performed  on 
data,  and  the  results  arc  w  ritten  back  over  data  dial  is  no  longer  needed.  Temporary  storage  is  allocated  to 
contain  intermediate  results.  Since  there  is  no  run-time  storage  management,  the  layout  of  local  storage  is 
static  and  mast  be  established  at  compile-time.  There  is  no  natural  way  to  implement  stacks,  arrays,  or  heaps. 
The  programmer  has  a  complete  model  of  the  usage  of  each  bit  in  a  cell’s  local  storage. 

Programmers  most  commonly  deal  with  the  lack  of  synchronization  or  queueing  features  in  the  message 
transmission  facility  by  limiting  die  circulation  of  a  cell’s  address.  Adoption  of  appropriate  conventions  about 
the  handling  of  pointers  can  guarantee  dial  no  more  dian  one  cell  will  ever  wish  to  transmit  messages  to  any 
given  cell.  If  many  cells  might  potentially  wish  to  communicate  with  some  target  cell,  then  a  tree  of 
iniermediau  cells  can  be  built  to  handle  the  "fan-in"  of  messages,  effectively  constructing  a  queue  out  of  cells. 
(See  ( 1 1 1. )  Other  higher-level  protocols  can  be  supported  by  appropriately  coordinating  message 
transmission,  and  by  building  auxiliary  supporting  structures  out  of  cells.  To  a  large  extent,  die  design  of 
algorithms  lor  the  CM  is  the  design  of  such  communications  protocols. 

Sometimes  the  representation  of  an  object  that  die  programmer  wishes  to  treat  atomically  will  require 
more  storage  than  that  of  a  single  cell.  In  this  case,  several  cells  must  be  allocated  and  linked  together,  by  a 
mutual  exchange  of  addresses  if  nothing  else.  Ibis  forces  the  programmer  to  deal  with  internal 
communications  within  her  data-siruciures.  as  well  as  external  communications  between  them. 
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CL1  Summary 

The  chief  motivation  behind  the  design  of  Cl.l  was  the  observation  that  the  storage  management  in  a 
single  CM  processing  element  closely  parallels  management  of  the  registers  in  a  conventional  general- register 
von  Neumann  machine.  Many  expressions  in  a  conventional  programming  language  can  be  compiled  into 
"straight-line"  code  which  uses  only  the  fixed  storage  contained  in  the  register  file  of  a  conventional  machine. 
Since  a  single  CM  eel!  contains  about  the  same  amount  of  storage  as  a  conventional  register  file,  such  code 
can  be  executed  on  a  single  CM  cell.  This  suggested  that  we  try  programming  individual  cells  in  such  a 
language.  We  can  support  message  passing  by  simply  adding  primitive  transmitting  and  receiving  operators 
to  our  language. 

Having  chosen  to  view  programming  a  CM  in  this  manner,  we  built  a  compiler  using  off-the-shelf 
compiler  technology.  We  drew  on  techniques  from  [12}.  as  well  as  some  more  standard  techniques  such  as 
those  found  in  (2).  lhc  resulting  language,  a  dialect  of  Lisp  resembling  Scheme  [14},  is  documented 
completely  in  [4). 

Cl.l  programs  arc  thought  of  as  executed  by  single  CM  cells.  This  limits  the  kind  of  programs  that  can  be 
executed.  Since  each  cell  has  a  fixed  number  of  bits  of  suite,  programs  requiring  unbounded  suite  will  not  be 
executable.  Cl.l  disallows  two  features  which  in  more  powerful  Lisps  allow  programs  to  employ  unbounded 
state:  recursion  other  than  tail-recursion,  and  runtime  closures.  Truncated  in  this  manner.  CL1  cannot  be 
used  for  programs  that  require  more  than  a  fixed  amount  of  state,  as  determined  at  compile  time.  Cl.l  is 
basically  a  language  for  writing  finite  suite  machines. 

In  the  CL1  model  of  a  CM.  every  allocated  cell  is  in  some  "suite".  Each  suite  has  associated  with  it  a 
number  of  "state  variables",  lhc  values  of  these  variables  at  any  cell  in  that  suite  arc  stored  in  bits  allocated 
from  that  cell's  local  storage.  Also  associated  with  each  suite  is  a  straight-line  (non-branching)  piece  of  code  to 
be  run  by  any  cell  in  that  suite.  That  code  performs  compilations  with  the  cell's  suite  variables,  computes  a 
new  suite  for  it.  and  provides  values  for  any  new  suite  variables. 

It  is  the  Cl.l  compiler's  job  to  hide  this  state-machine  model  of  program  execution  from  the  programmer 
wherever  possible.  The  programmer  normally  expresses  the  behavior  of  cells  in  a  flexible.  I  isp-likc  language. 
However,  sometimes  the  programmer  must  explicitly  talk  about  a  suite  with  its  associated  variables  and  code. 
This  is  usually  done  using  the  DE  FST  AT  E  form,  which  allows  a  programmer  to  give  a  name  u>  a  suite: 

(DEFSTATE  FACTORIAL-STATE  (NUMBER) 

(LABELS  ((FACT  (LAMBDA  (ACCUMULATOR  COUNTER) 

(IF  (<  COUNT  2)  ACCUMULATOR 

(FACT  (*  COUNTER  ACCUMULATOR) 

(l-  COUNTER)))))) 

(GO  NEXT-STATE  (FACT  1  NUMBER)  NUMBER))) 

This  form  defines  a  stale  named  FACTORIAL  -  STATE,  with  a  single  state  variable  named  NUMBER.  If.' tell  is 
placed  m  slate  FAC  1 0R1 AL -SI  ATE  and  its  stale  v.uialile  is  initialized  to  contain  some  integer,  that  cell  will 
proceed  to  compute  the  factorial  ol  that  number.  When  it  is  finished,  it  will  set  its  state  to  NEXT  SI  ATE. 
initializing  Us  first  st  ile  tunable  to  contain  the  newly  tompiiled  lnclori.il  and  Us  second  state  variable  to 
contain  the  oi iginal  number. 
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Notice  dial  most  of  the  body  of  a  DEFSTATE  form  looks  like  ordinary  I.isp  code.  This,  after  all.  was  the 
major  goal  in  implementing  Cl  .1 :  to  allow  familiar  tools  to  be  applied  to  CM  programming. 

Support  for  message  passing  in  Cl  I  is  quite  simple.  A  cell  can  have  a  number  of  channels  to  receive 
messages.  The  TRANSMIT  function  takes  a  pointer  to  a  channel  in  another  cell  and  a  message  and  causes  that 
message  to  arrive  as  input  in  that  channel.  T  he  WITH-CHANNEL  special  form  allocates  a  location  within  the 
executing  cell  to  be  a  channel  and  creates  a  pointer  to  that  location,  e.g.. 

(WITH-CHANNEL  (CHANNEL  POINTER) 

(MAKE-CELL  NEW-CELL-STATE  POINTER) 

(INPUT  CHANNEL)) 

In  this  example,  the  variable  POINTER  will  be  bound  to  the  new  pointer  and  the  variable  CHANNEL  will  be 
bound  to  the  "channel  object"  at  which  the  pointer  points.  A  pointer  points  to  a  channel  within  a  cell,  not  to 
the  cell  itself.  The  location  of  the  channel  will  be  deallocated  when  the  body  of  the  WITH-CHANNEL  form  is 
finished  executing.  T  he  cell  will  be  able  to  read  any  message  transmitted  to  it  using  this  pointer  by  applying 
the  INPUT  function  to  the  channel.  In  the  example  the  executing  cell  creates  a  pointer-channel  pair,  allocates 
a  new  cell  using  the  MAKE -CELL  function  (not  a  trivial  operation;  see  [6]).  places  that  new  cell  in  the  state 
NEW-CELL-STATE,  initializes  its  single  shite  variable  to  contain  the  new  pointer,  and  then  waiLs  for  a 
message  to  arrive  from  die  new  cell.  A  version  of  TRANSMIT,  called  TRANSMIT -WAIT,  performs  arbitration 
when  more  dian  one  cell  sends  a  message  to  the  same  channel  at  the  same  time.  Kach  TRANSMIT-WAIT  call 
hangs  until  the  receiving  cell's  INPUT  call  gets  around  to  that  message.  The  TRANSMIT-WAIT  construct  is 
not  a  hardware  primitive;  it  compiles  to  a  complex  protocol. 

Since  CI.l  has  no  theory  of  daui  other  than  providing  a  pointer  datatype  to  represent  CM  addresses,  the 
values  manipulated  by  CI.l  programs  in  the  present  implementation  arc  simply  Macl.isp  objects.  Data  types 
other  than  CI  .l  pointers  are  left  to  the  programmer  to  simulate  as  best  she  can.  Short  fixed-length  lists,  for 
example,  are  commonly  used  to  implement  records.  The  programmer  is  on  her  honor  not  to  use  these  objects 
in  ways  that  arc  clearly  impossible  on  an  actual  CM. 

Coding  cliches 

In  the  course  of  writing  the  first  few  Cl  .1  programs,  a  number  of  conventions  and  coding  cliches  arose  that 
we  have  tried  to  capture  with  macros.  Here  we  present  the  ones  that  arc  convenient  to  explain  outside  the 
context  ol  die  Scheme  interpreter  described  in  the  next  section. 

I  {very  channel  in  a  cell  uses  one  of  two  message-passing  contracts.  A  continuation  is  a  channel,  typically 
created  as  a  pl.ice  for  another  cell  to  send  die  result  of  its  calculation,  to  which  there  is  exactly  one  pointer  in 
the  system.  One  uses  TRANSMI T  to  send  a  message  to  a  continuation.  A  connnaml  channel  is  used  by  a  cell  lo 
olier  some  contract  lo  any  taker.  Messages  to  command  channels,  called  coniniamh.  are  sent  using 
T  RANSM  IT  WAIT.  A  command  has  a  i  onnnaiul  type  and  a  lived  numhci  of  fields,  Ihc  Ill's!  of  which  must  be 
a  continuation  to  which  the  response  should  he  sent. 

When  a  cell  creates  a  new  tell  with  MAKE -CELL,  the  following  scheme  is  often  used  to  establish 
commtuiK  moil  between  the  new  cell  and  its  owner.  I  he  new  cell  will  have  among  its  initial  stale  variables 
one  v ailed  t  V.'fJI  It.  w hit'll  is  uiiii.ili/cd  lo  a  pointer  lo  an  input  channel  in  the  cell  that  made  it.  T  he  newly 
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created  cell  is  expected  to  send  to  llte  owner's  channel  a  pointer  to  a  channel  of  its  own. 


Many  types  of  cells  arc  quite  passive,  merely  handling  one  command  after  another.  Such  command-bop 
cells  recall  the  "objects"  of  languages  like  Smalltalk.  As  an  example,  here  is  a  piece  ofCl.l  code  taken  from 
the  Scheme  interpreter  that  illustrates  these  three  conventions: 

(DEFSTATE  CONS-NODE  (OWNER  CAR-PART  CDR-PART ) 

( WITH'CHANNEL  (COMMAND-CHANNEL  COMMAND -POINTER) 

(TRANSMIT  OWNER  COMMAND-POINTER) 

(DO  ((COMMAND  (INPUT  COMMAND -CHANNEL) 

(INPUT  COMMAND-CHANNEL))) 

(NIL) 

(DISPATCH  COMMAND 

((GET-CAR  CONTINUATION) 

(TRANSMIT  CONTINUATION  CAR-PART)) 

( ( GET-CDR  CONTINUATION) 

(TRANSMIT  CONTINUATION  CDR-PART)) 


A  CONS-NODE  sends  its  owner  a  pointer  to  its  command  channel  and  then  enters  an  eternal  loop,  dispatching 
off  die  type  of  each  new  command  and  transmitting  the  appropriate  answer  to  the  command's  continuation. 
ITic  DE  FOB  JECT  macro  can  be  used  to  suppress  the  first  four  lines  of  this  definition: 

(DEFOBJECT  CONS-NODE  (CAR-PART  CDR-PART)  (COMMAND) 

(DISPATCH  COMMAND 

((GET-CAR  CONTINUATION)  (TRANSMIT  CONTINUATION  CAR-PART)) 

((GET-CDR  CONTINUATION)  (TRANSMIT  CONTINUATION  CDR-PART)) 

)) 

T  he  DISPATCH  form  dispatches  on  the  type  of  a  command,  locally  binding  die  fields  of  the  command  to 
variables.  'Hie  clause  of  a  DISPATCH  corresponding  to  a  given  type  of  command  is  commonly  called  that 
command's  method.  The  code  for  CONS-NODE  has  a  GET-CAR  method  and  a  GET-CDR  method. 


One  commonly  sends  a  cell  a  command  and  calls  INPUT  on  the  provided  continuation  to  await  a  response. 
T  he  DEFCOMMAND  macro  can  be  used  to  define  a  Functional  form  to  capture  this  cliche,  l-'or  example. 
(DEFCOMMAND  GET-CAR  (CONS-NODE))  allows  one  to  obtain  die  CAR-PART  of  a  CONS-NODE  by 
saying  (GET-CAR  cell).  This  form  will  expand  into: 

( W1TH-CHANNEL  (TEMPORARY-CHANNEL  TEMPORARY-POINTER) 

(TRANSMIT -WAIT  cell 

(MAKE-COMMAND  'GET-CAR  TEMPORARY-POINTER)) 

(INPUT  TEMPORARY-CHANNEL)) 

Notice  dial  a  cell  that  uses  GET-CAR  or  any  other  DEFCOMMAND  form  must  sit  waiting  in  INPUT  until  the 
target  cell  computes  and  returns  the  answer. 


The  DT  F MAKER  macro  delines  a  functional  form  to  create  a  cell  that  employs  the  OWNER  convention,  e.g.. 
( III  I IIAKI  li  CONS  NODE  (  CAR  PAR  I  CUR  PAR  I  ) )  lets  one  obtain  a  pointer  to  the  command  channel  ol  a 
new  h  clc.ilci!  CONS  NOltf  by  say  ni;’  (  MAM  CON'i  NtilU  ,.n  />.»/«.  /»-/•.«/).  I  Ins  loini  will  expand  into: 


(WITH-CHANNEL  (TEMPORARY -CHANNEL  TEMPORARY-POINTER) 

(MAKE-CELL  CONS-NODE  TEMPORARY-POINTER  cat-pan  cdrpan) 

(INPUT  TEMPORARY-CHANNEL)) 

Scheme  interpreter 

To  see  what  programming  in  Cl. I  is  like,  we  wrote  an  interpreter  for  Scheme,  a  lexically  scoped  and 
tail- recursive  dialect  of  I  .isp.  The  most  obvious  interest  of  this  exercise  is  the  promise  of  being  able  to  employ 
arbitrarily  differentiated  processing  on  the  putatively  SIMI)  Connection  Machine:  by  multiplexing  the  CM's 
instruction  stream  among  the  different  kinds  of  objects  in  a  running  Scheme  program,  thousands  of  different 
Scheme  prog  aim  can  be  executed  in  parallel  at  the  cost  of  a  moderate  constant  factor  slow-down.  (A  similar 
tack  is  Liken  in  [9].)  Kvcn  so.  we  don't  consider  Scheme  to  be  particularly  well-suited  for  programming 
parallel  machines:  it  provides  no  better  account  than  the  average  language  of  the  important  linguistic  issues  of 
how  best  to  express  methods  of  process  decomposition  and  synchronization. 

We  chose  Scheme  interpretation  as  our  first  experiment  in  Cl.l  programming  not  because  Scheme  is  the 
ultimate  parallel  programming  language  but  because  the  Scheme  interpreter  is  an  interesting  and  relatively 
simple  algorithm  that  we  understand  thoroughly.  There  is  an  extensive  literature  and  culture  of  the 
implementation  of  Scheme  and  its  neighbors  in  languagc-spacc  (sec  [15]).  The  Turing-univcrsality  of  the 
algorithm  provides  some  vague  promise  that  a  wide  variety  of  programming  issues  must  be  addressed  in  its 
implementation.  A  less  familiar  programming  problem  would  have  introduced  uncertainties  unrelated  to  the 
linguistic  issues  that  were  our  real  interest. 

We  assume  that  the  reader  has  a  reasonable  grounding  in  Scheme  and  the  issues  involved  in  its 
interrelation:  sec  [14]  or  [1],  l-or  our  purposes,  the  most  important  features  of  a  Scheme  interpreter  arc: 

•  The  language  is  lexically  scoped  (as  is.  for  example.  Algol-60).  A  procedure  object  is  created  by 
combining  a  pointer  to  the  body  of  the  procedure  with  a  pointer  to  the  current  environment.  When  a 
procedure  object  is  applied  to  arguments,  the  body  is  interpreted  in  an  environment  constructed  by 
extending  die  procedure  object's  environment  with  the  new  bindings  of  the  procedure's  formal 
parameters. 

•  Procedure  objects  are  first-class  data:  they  can  be  passed  as  arguments,  returned  .is  values,  and 
incorporated  into  compound  data  structures.  T  hat  one  should  be  able  to  make  general  use  of  procedure 
objects  without  excessive  penalty  is  part  of  die  Scheme  programming  philosophy  and  a  strict  constraint 
on  die  Scheme  implementor. 

•  \  Scheme  interpreter  must  be  t<iil-nrursi\c.  While  a  recursive  procedure  must  wait  for  the  result 
tr» mt  its  reclusive  call  so  it  can  perlbrm  additional  operations  w  uh  that  result,  a  tail-iecursivc  procedure, 
having  no  additional  operations  to  perform,  need  not  push  a  return  address.  (See  |l  t|.)  The  interpreter, 
when  calling  itself  on  a  subexpression  of  a  given  expression,  saves  only  the  intormniion  that  will  he 
needed  alter  the  evaluation  of  the  subexpression  has  been  completed.  In  addition  to  allowing  users  to 
use  procedure  calls  liberally,  this  allows  efficient  implementation  ol  all  common  control  constructs  in 
terms  ol  conditional  evaluation  and  (he  procedure  call. 


In  our  Cl.l  Scheme  interpreter,  a  program  is  represented  as  a  network  of  cells  that  is  produced  as  a  parse 
tree  by  a  syntaxcr  (roughly  speaking,  a  parser).  For  instance.  Figure  1  portrays  the  network  corresponding  to 
the  expression: 

(DEFINE  MAKE-INCREMENTER 
(LAMBDA  (INCREMENT) 

(LAMBOA  (X) 

(PLUS  INCREMENT  X)))) 

To  evaluate  a  Scheme  expression  in  an  environment,  one  sends  it  an  EVALUATE  command,  providing  a 
continuation  and  the  environment  implemented  as  a  chain  of  FRAME  and  ALIST  cells.  Figure  2  shows  a 
portion  of  the  global  environment  after  the  definition  of  MAKE-INCREMENTER  has  been  evaluated  by 
sending  such  a  command  to  the  DEFINITION  cell  at  the  top  of  the  tree.  Figure  3  shows  the  environment 
after  the  form  (DEFINE  INCREMENTER  (MAKE-INCREMENTER  7 ))  has  been  syntaxed  and  evaluated. 

The  contract  of  an  EVALUATE  command  is  that  the  result  of  cvaluting  the  receiving  expression  in  the 
indicated  environment  should  eventually  be  sent  to  the  indicated  continuation.  On  a  serial  machine,  the 
Scheme  evaluator  dispatches  on  die  type  of  die  cell  being  evaluated,  but  in  our  interpreter  each  object  knows 
how  to  evaluate  itself.  (This  is  reminiscent  of  what  on  serial  machines  is  called  object-oriented  programming.) 
There  arc  eight  types  of  cells  in  a  program: 

COND I T I ONALs.  as  in  ( I F  predicate  then  else) 

VARIABLES,  such  as  CAR  and  PATTERN 
DEFINITIONS,  as  in  (DEFINE  symbol  expression) 

LAMBDA-EXPRESSIONs.  as  in  (LAMBDA  variables  body) 

PROCEDURE -APPLICATIONS  and  OPERAND-CONScs.  as  in  (procedure  .  operands) 

SEQUENCES,  as  in  (SEQUENCE  .  expressions) 

PARALLELS,  as  in  (PARALLEL  .  expressions) 

CONSTANTS,  such  as  (QUOTE  (EATS  KITTY  FISH))  and  23 

As  an  example,  consider  the  CONDITIONAL  cell  type.  It  has  state  variables  called  PREDICATE ,  THEN,  and 
ELSE,  each  pointing  at  the  cell  for  some  other  Scheme  expression.  Here  is  one  way  that  die  CONDITIONAL 
cell  could  have  been  implemented: 

(DEFOBJECT  CONDITIONAL  (PREDICATE  THEN  ELSE)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

( TRANSMIT-WAIT  (IF  (EVALUATE  PREDICATE  ENVIRONMENT) 

THEN 

ELSE) 

COMMAND)) 

)) 

A  CONDI  T I ONAL  cell  .icccpts  a  stream  of  F VAl UAT C  commands.  It  use's  the  EVALUATE  form  defined  using 
DT  F COMMAND  to  find  die  value  of  the  piedieate  and  hands  the  result  to  Cl  1  's  IF.  which  determines  whether 
TltTN  or  ELSE  will  he  evaluated  to  provide  the  result.  Ihe  winning  expression  is  sent  the  command  the 
CONDI  I IONAL  received,  and  so  will  pass  its  result  on  to  that  command's  continuation  itself.  Meanwhile.  Ihe 
CONDI  I1UNAI  cell  can  move  on  to  new  LVAlUAtl  commands.  I lus  coiitinuation-pasMng  iikL  tcf.|lt>|) 


Figure  1.  CM  representation  of  a  Scheme  program. 

The  syntaxcr  for  our  Cl.l  Scheme  interpreter  lays  out  a  Scheme  program  in  the  CM  as  a  tree  of  celts,  one 
for  e;tch  part  of  the  code.  To  evaluate  a  piece  of  Scheme  code  in  some  environment,  one  sends  the  cell  at  the 
top  of  the  tree  a  command  of  the  form  (EVALUATE  continuation  environment).  The  network  corporately 
guarantees  that  the  right  answer  will  eventually  arrive  at  the  continuation. 
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Figure  2.  After  defining  MAKE- INCREMENTER. 

A  CL1  Scheme  environment  is  organized  as  a  sequence  of  FRAMES,  each  of  which  is  composed  of  a 
sequence  of  binding  pairs  (a  chain  of  ALIST  cells).  LOOKUP  and  SET-VARIABLE  commands  propagate  - — 1 

from  a  FRAME  to  its  chain  of  ALIST  cells,  and  from  the  last  ALIST  to  the  following  FRAME.  Procedures  arc  ‘ 

data  objects  like  any  others  and  a  procedure  is  normally  fetched  by  looking  its  name  up  in  die  current  V- 

environment.  Ihc  object  that  embodies  the  procedure  is  a  cell  of  type  CLOSURE.  A  CLOSURE  is  created  by 
the  evaluation  of  a  LAMBDA-EXPRESSION  and  contains  not  only  the  parameter  list  and  body  of  the  ^ 

LAMBDA-EXPRESSION  but  also  the  environment  that  was  current  when  the  LAMBDA-EXPRESSION  was 
evaluated.  The  body  will  be  evaluated  in  this  environment  when  the  CLOSURE  is  applied  to  arguments. 


Figure  3.  After  defining  INCREMENTER. 

When  (DEFINE  INCREMENTER  (MAKE-INCREMENTER  7))  is  evaluated,  a  new  AL I  ST  cell  is  created  in 
the  global  environment;  this  cell  binds  INCREMENTER  to  a  new  CLOSURE.  A  new  FRAME  is  created  to  serve 
as  the  environment  of  that  closure,  in  which  X  has  the  value  7.  The  new  FRAME'S  parent  environment  is  the 
global  environment 
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corrcsponds  to  the  tail-recursive  nature  of  the  evaluation  of  conditionals  in  serial-machine  Scheme 
interpreters. 


Yet  conditional  evaluation  isn’t  quite  tail-recursive,  since  the  CONDITIONAL  cell  must  wait  on  the  result  of 
the  evaluation  of  the  predicate.  If  that  predicate  is  a  complicated  expression,  a  large  number  of  new 
commands  could  back  up  in  live  CONDITIONAL'S  input  queue.  Not  only  that,  but  if  the  evaluation  of  the 
predicate  involves  evaluating  that  same  CONDI  TIONAL  in  some  environment,  the  system  will  deadlock  with 
the  CONDITIONAL  and  its  predicate  waiting  on  one  another. 


Therefore,  the  CONDITIONAL  creates  a  temporary  cell  to  wait  on  the  value  of  the  predicate  and  pass  the 
EVALUATE  command  on  to  THEN  or  ELSE: 


(DEFOBJECT  CONDITIONAL  (PREDICATE  THEN  ELSE)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

(TRANSMIT-WAIT  PREDICATE 
(MAKE -COMMAND  ’EVALUATE 
(FORK  (RESULT-CHANNEL) 

(TRANSMIT-WAIT  (IF  (INPUT  RESULT-CHANNEL)  THEN  ELSE) 

COMMAND ) ) 

ENVIRONMENT))) 

)) 

(MAKE -COMMAND  makes  commands',  it  shouldn't  be  confused  with  the  forms  created  by  DEFMAKER.)  The 
FORK  macro  suppresses  tire  details  of  making  a  temporary  cell  to  wait  on  the  predicate  outcome  and  then 
perform  the  inner  TRANSMIT-WAIT.  Ihe  user  thinks  of  the  FORK  form  as  returning  a  pointer  to  the 
temporary  cell's  RESULT -CHANNEL:  this  is  the  continuation  for  the  evaluation  of  the  predicate.  Here  is  the 
code  into  which  the  FORK  form  expands: 


(WITH-CHANNEL  (TEMP-CHANNEL  TEMP-POINTER) 

(MAKE-CELL  (KAPPA  (TEMP-OWNER) 

(WITH-CHANNEL  (RESULT-CHANNEL  RESULT-POINTER) 

(TRANSMIT  TEMP-OWNER  RESULT-POINTER) 

(TRANSMIT-WAIT  (IF  (INPUT  RESULT-CHANNEL) 

THEN 

ELSE) 

COMMAND ) ) ) 

TEMP-POINTER) 

(INPUT  TEMP-CHANNEL)} 

Cl  Is  KAPPA  allows  one  to  create  anonymous  states  by  analogy  to  the  Scheme  LAMBDA  construct  for  creating 
anony  mous  procedures.  I  he  temporary  cell.  then,  is  started  up  in  a  state  in  which  it  creates  a  channel,  sends  a 
pointer  to  it  to  its  owner  in  the  traditional  manner,  and  waits  lor  the  outcome  of  the  predicate  to  arrive  in  that 
channel.  After  sending  the  otiginal  COMMAND  to  either  THtN  or  ELSE  the  temporary  cell  becomes  garbage. 
(Cl  I  extends  the  analogy  between  KAPPA  and  I  AMIIUA  bv  making  sure  that  variables  free  in  a  KAPPA  form, 
in  this  ease  COMMAND.  IMF  N.  and  E  l  SF.  are  automatically  transmitted  to  any  cell  created  in  the  slate  defined 
In  the  form.) 


The  temporary  cell  cie.ited  in  this  process  is  analogous  to  the  stack  space  that  a  soiial-m.ichine  Scheme 


interpreter  must  occupy  during  its  recursive  call  on  the'  predicate  of  a  conditional.  Such  cells  arc  used  in 
several  places  in  the  Cl  .1  Scheme  interpreter,  each  of  them  corresponding  to  a  non-tail-rccursivc  call  in  the 
usual  meta-circular  (that  is.  written  in  Scheme)  Scheme  interpreter  (sec  [15)).  Tail-recursion  in  the  CL1 
Scheme  interpreter  both  increases  the  throughput  of  cells  by  not  making  them  wait  for  answers  and  saves 
space  by  not  making  them  create  temporary  cells  to  do  that  waiting. 

Thus  the  evaluation  of  a  CONDITIONAL  cell  involves  little  more  than  passing  the  EVALUATE  command 
off  to  other  celts.  A  similar  tack  is  taken  by  PROCEDURE-APPLICATION  cells: 

(DEFOBJECT  PROCEDURE-APPLICATION  (PROCEDURE  OPERAND-LIST)  (COMMAND) 
(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

(TRANSMIT-WAIT  PROCEDURE 
(MAKE -COMMAND  'EVALUATE 
(FORK  (RESULT-CHANNEL) 

(TRANSMIT-WAIT  (INPUT  RESULT-CHANNEL) 

(MAKE -COMMAND  'EVLIS 
CONTINUATION 
OPERAND-LIST 
ENVIRONMENT))) 

ENVIRONMENT))) 

)) 

When  a  PROCEDURE-APPLICATION  cell  receives  an  EVALUATE  command,  it  must  evaluate  the 
PROCEDURE  expression  in  the  provided  environment  and  then  tell  the  resulting  closure  to  evaluate  the 
operands  and  apply  itself  to  the  resulting  arguments.  Rather  than  wait  for  that  evaluation  of  PROCEDURE  to 
rciurn  a  value,  though,  it  uses  the  FORK  form  to  create  a  temporary  cell  to  do  the  waiting  and  send  the  EVLIS 
command  to  the  closure.  Once  the  forked  cell  finishes  sending  the  EVLIS  command,  it  has  no  more  code  to 
execute  and  so  passes  into  the  null  state  and  is  deallocated. 

A  closure  in  Scheme  is  an  object  created  by  the  evaluation  of  a  LAMBDA  expression.  It  contains  the 
parameters .  nd  body  given  in  the  LAMBDA  together  with  die  environment  that  was  current  when  the  LAMBDA 
expression  was  evaluated.  When  a  procedure  is  applied  to  operands,  the  operands  arc  evaluated  in  the 
current  environment:  once  the  parameters  have  been  bound  to  the  resulting  arguments,  the  body  of  the 
procedure  is  evaluated  in  the  environment  that  is  stored  in  the  closure.  That  the  closure  and  not  the  caller 
determines  the  environment  of  evaluation  lor  the  body  of  a  newly  culled  procedure  is  the  essence  of  Scheme's 
lexical  scope,  as  opposed  to  the  dynamic  scope  of  traditional  l  isp. 

In  our  implementation,  a  cell  of  type  CLOSURE  is  created  by  the  evaluation  of  a  LAMBDA- EXPRESSION 
object  in  some  environment: 

(DFTOBJECT  LAMBDA-EXPRESSION  (SYMBOLS  BODY)  (COMMAND) 

(DISPATCH  COMMAND 

(( EVALUATE  CONTINUATION  ENVIRONMENT ) 

(MAKE-CELL  CLOSURE  C0NI1NUAT1UN  ENVIRONMENT  SYMBOLS  BODY)) 

)) 

A  CEOSIIRF  processes  F VI  IS  commands  sent  Co  it  by  PROCEDURE  -  APPI  ICAT  IONs.  The  fields  of  an 
I  VI  IS  ii'in  Hand  are:  (I)  the  continuation  to  which  the  eventual  ivmiIi  is  to  be  sent.  (1)  the  nnevalu.iled 
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opcrand  list,  and  (3)  the  environment  in  which  these  operands  arc  to  be  evaluated: 

(DEFOBJECT  CLOSURE  (ENVIRONMENT  PARAMETERS  BODY)  (COMMAND) 

(DISPATCH  COMMAND 

((EVLIS  CONTINUATION  OPERANDS  OPERAND-ENVIRONMENT) 

(TRANSMIT-WAIT  BODY 

(MAKE -COMMAND  ’EVALUATE 
CONTINUATION 
(MAKE-FRAME  ENVIRONMENT 
PARAMETERS 
OPERANDS 

OPERAND-ENVIRONMENT) ) ) ) 

)) 

Upon  receiving  and  dcstructuring  the  EVLIS  command.  Die  CLOSURE  object  extends  the  environment  and 
tail-rccursivcly  initiates  the  evaluation  of  the  body  in  the  resulting  environment.  The  MAKE -FRAME  form, 
which  initiates  the  process  of  evaluating  the  operands  and  extending  the  environment  docs  not  wait  for  that 
process  to  finish:  instead  it  immediately  returns  a  pointer  to  the  FRAME  that  will  lie  at  the  head  of  the 
extended  environment. 


It  is  the  responsibility  of  a  FRAME,  then,  to  see  that  the  operands  arc  evaluated  and  bound  to  symbols  in 
fresh  ALIST  cells.  After  identifying  itself  to  its  owner,  it  starts  a  BIND  command  propagating  down  the 
operand  list  This  results  in  a  pointer  to  the  first  of  a  newly  created  ALIST  chain  being  returned  to  it, 
whereupon  it  settles  into  a  command  loop. 

(DEFSTATE  FRAME  (OWNER  NEXT-FRAME  PARAMETERS  OPERANDS  ENVIRONMENT) 
(WITH-CHANNEL  (COMMAND-CHANNEL  COMMAND- POINTE R ) 

(TRANSMIT  OWNER  COMMAND-POINTER) 

(LET  ( ( INITIAL-ALIST 
(IF  OPERANDS 

(BIND  OPERANDS  PARAMETERS  ENVIRONMENT  NEXT-FRAME) 
NEXT-FRAME))) 

(ITERATE  FRAME-LOOP  ((ALIST  INITIAL-ALIST)) 

(LET  ((COMMAND  (INPUT  COMMAND-CHANNEL))) 

(DISPATCH  COMMAND 

((LOOKUP  CONTINUATION  SYMBOL) 

(TRANSMIT-WAIT  ALIST  COMMAND) 

(FRAME-LOOP  ALIST)) 

((SET-VARIABLE  CONTINUATION  SYMBOL  VALUE) 

(TRANSMIT-WAIT  ALIST  COMMAND) 

(FRAME-LOOP  ALIST)) 

((DEFINE  CONTINUATION  SYMBOL  VALUE) 

(TRANSMIT  CONTINUATION  T) 

(FRAME-LOOP  (MAKE-ALIST  SYMBOL  VALUE  ALIST))) 

)))))) 


The  evaluation  of  operand  lists  is  a  little  tricky  and  not  entirely  pleasant.  An  operand  list  is  implemented 
as  a  chain  of  ORI  RAND -CONS  cells,  each  representing  one  of  the  operands.  When  an  OPF  RAND -CONS  cell 
receives  a  BIND  message,  it  evaluates  its  operand  expressions  in  the  provided  environment  and  builds  ALIST 
cells  Iiii  the  results  and  the  formal  parameters. 
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Thc  code  for  OPERAND-CONScs  and  ALISTs  requires  a  fair  bit  of  explanation.  'Hie  EXPRESSION 
variable  of  an  OPERANO-CONS  points  to  (the  command  channel  of)  the  operand,  which  is  some  arbitrary 
expression.  The  NEXT  variable  contains  either  NIL.  indicating  that  this  is  the  Last  operand,  or  a  pointer  to 
another  OPERAND-CONS  cell.  When  an  OPERAND-CONS  receives  a  BIND  command,  it  propagates  it  down 
the  chain,  making  a  new  AL  1ST  cell  at  every  step: 


(DEFOBJECT  OPERAND-CONS  (EXPRESSION  NEXT)  (COMMAND) 

(DISPATCH  COMMAND 

((BIND  CONTINUATION  PARAMETERS  ENVIRONMENT  NEXT-FRAME) 

(IF  (NULL  NEXT) 

(MAKE-CELL  LAST-PROTO-ALIST 
CONTINUATION 
(GET-CAR  PARAMETERS) 

EXPRESSION 

ENVIRONMENT 

NEXT-FRAME) 

(TRANSMIT-WAIT  NEXT 
(MAKE -COMMAND  ’BIND 

(MAKE -PROTO-AL 1ST  CONTINUATION 

(GET-CAR  PARAMETERS) 

EXPRESSION 

ENVIRONMENT) 

(GET-COR  PARAMETERS) 

ENVIRONMENT 

NEXT-FRAME)))) 

)) 

Before  undt rstanding  how  OPERAND-CONScs  work,  consider  one  way  they  might  have  worked.  An 
OPERAND-CONS  cell  could: 


( 1 )  evaluate  its  operand, 

(2)  'vail  while  subsequent  operands  arc  evaluated  to  yield  the  tail  of  the  new  chain  of  binding  pairs, 

(3)  ;  ttach  a  new  AL  I  ST  cell  that  binds  its  symbol  to  its  value  to  the  front  of  that  tail,  and 

(4)  return  the  newly  created  ALIST  to  the  continuation,  be  it  the  previous  OPERAND-CONS  cell  or 
the  CLOSURE  fork  that  is  waiting  on  the  new  environment. 

This  might  v  ork.  but  it  would  require  the  OPERAND-CONS  cells  at  the  front  to  spend  almost  all  their  time 
waiting  when  they  could  be  evaluating  their  expressions  in  the  service  of  other  CLOSURES.  Other  kinds  of 
cells,  like  CL  DSUREs.  solved  this  problem  by  using  the  FORK  form  to  make  a  temporary  cell  to  do  the  wailing. 

Hut  in  die  c.  sc  of  OPERAND-CONScs  there  is  no  need  to  go  to  the  extra  expense:  the  newly  created  ALIST 
cell  can  do  the  waiting  itself.  This  trick  is  the  reason  why  it  is  OPERAND-CONS  cells  that  evaluate  arguments 
rather  than  PROCEDURE -APPLICATION  cells,  as  a  direct  translation  of  the  usual  meta-circular  Scheme 
interpreter  it  to  Cl  1  would  have  it. 

I  here  arc  two  cases.  A  new  ALIST  can  wait  on  the  results  of  operand  evaluation  or  on  both  that 
evaluation  and  the  construction  ol  the  remaining  Al  IS  Is.  depending  on  whether  it  is  the  last  ALIST  in  that 
li  line.  Comequenlly.  there  are  two  different  states  in  which  an  ALIST  cell  can  In*  created.  PROTO-AL  1ST 
and  LAST  -  PROTO- AL 1ST: 

•Sv 
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(DEFSTATE  LAST-PROTO-ALIST  (OWNER  SYMBOL  EXPRESSION  ENVIRONMENT  NEXT) 
(GO  ALIST  OWNER  SYMBOL  (EVALUATE  EXPRESSION  ENVIRONMENT)  NEXT)) 

(DEFSTATE  PROTO-ALIST  (NEXT-SOURCE  OWNER  SYMBOL  EXPRESSION  ENVIRONMENT) 
(WITH-CHANNEL  ( EVAL-CHANNEL  EVAL-POINTER) 

(TRANSMIT-WAIT  EXPRESSION 

(MAKE -COMMAND  ’EVALUATE  EVAL-POINTER  ENVIRONMENT)) 

(WITH-CHANNEL  (NEXT-CHANNEL  NEXT-POINTER) 

(TRANSMIT  NEXT-SOURCE  NEXT-POINTER) 

(GO  ALIST 
OWNER 
SYMBOL 

(INPUT  EVAL-CHANNEL) 

(INPUT  NEXT-CHANNEL))))) 

(DEFSTATE  ALIST  (OWNER  BOUND-SYMBOL  INITIAL -VALUE  NEXT) 

(WITH-CHANNEL  (COMMAND-CHANNEL  COMMAND-POINTER) 

(TRANSMIT  OWNER  COMMAND- POINTER) 

(ITERATE  ALIST-LOOP  ((VALUE  INITIAL-VALUE)) 

(LET  ((COMMAND  (INPUT  COMMAND-CHANNEL))) 

(DISPATCH  COMMAND 

((LOOKUP  CONTINUATION  SYMBOL) 

(COND  ( ( EQ  SYMBOL  BOUND-SYMBOL) 

(TRANSMIT  CONTINUATION  VALUE)) 

((NOT  (NULL  NEXT)) 

(TRANSMIT-WAIT  NEXT  COMMAND)) 

(T 

( FORMAT  T 

"UNBOUND  SCHEME  VARIABLE:  ~S" 

SYMBOL))) 

(ALIST-LOOP  VALUE)) 

((SET-VARIABLE  CONTINUATION  SYMBOL  NEW-VALUE) 

(COND  ( ( EQ  SYMBOL  BOUND-SYMBOL) 

(TRANSMIT  CONTINUATION  T) 

(ALIST-LOOP  NEW-VALUE)) 

((NOT  (NULL  NEXT)) 

(TRANSMIT-WAIT  NEXT  COMMAND) 

(ALIST-LOOP  VALUE)) 

(T 

(FORMAT  T 

"ATTEMPT  TO  SET  AN  UNBOUND  VARIABLE:  ~S" 

SYMBOL ) 

(ALIST-LOOP  VALUE)))) 

))))) 

There  is  quilc  a  bit  going  on  here.  Here  is  the  image:  as  the  BIND  command  propagates  down  the  chain  of 
OPE  RAND- CONS  cells,  a  parallel  chain  oT  PROTO-ALIST  cells  is  created,  each  of  which  has  initiated  the 
evaluation  of  its  corresponding  operand  and  is  waiting  for  the  next  ALIST  cell  along  to  identify  itself.  When 
the  BIND  command  reaches  the  last  OPERAND-CONS  cell  along,  control  "turns  around"  at  a 
LAST  PROTO-ALIST  cell,  propagating  hack  along  the  chain  of  proto-ahst  cells.  e;tch  of  which  initializes 
itself  in  turn  by  tinning  into  the  Al  IST  stale.  (Opeiainls  are  thus  evaluated  in  parallel.)  The  process  is 
completed  when  the  lirsl  ALIST  cell  in  the  chain  identities  itself  to  the  new  FRAME. 
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Wc  uscc  such  a  peculiar  pattern  of  message  sending  and  receiving  to  implement  operand  list  evaluation  so 
that  no  cell  that  could  be  doing  useful  work  has  to  wait  for  anything.  In  particular,  we  don't  want  the 
OPERAND -CONS  that  creates  a  new  binding  pair  to  have  to  wait  for  all  the  downstream  binding  pairs  to  be 
created  fir >t.  But  each  ALIST  cell  requires  a  pointer  to  its  successor.  Consequently,  when  an 
OPERAND-CONS  cell  creates  a  PROTO-ALIST  cell,  the  PROTO-ALIST  cell  returns  to  it  a  pointer  (called 
NEXT-POINTER)  to  a  channel  (called  NEXT-CHANNEL)  to  which  (a  pointer  to  the  command  channel  of)  the 
next  ALIST  cell  along  should  be  sent  once  it  is  known.  This  pointer  is  sent  along  to  the  next 
OPERAND-CONS  as  part  of  the  BIND  message.  The  boundary  ease  of  this  process  is  at  the  last 
OPERAND-CONS,  for  which  the  correct  value  of  the  new  ALIST  cell’s  NEXT  variable  is  known.  (This  value  is 
not  NIL.  hut  rather  the  next  frame  in  the  environment,  where  failed  LOOKUP  and  SET-VARIABLE 
commands  should  be  propagated.)  Therefore.  LAST  -  PROTO-AL  1ST  cells  perform  only  half  of  this  complex 
protocol:  tfey  wait  on  the  evaluation  of  the  operand,  but  arc  given  the  NEXT  right  away  rather  than  having  to 
wait  for  it  a>  well. 

Once  an  ALIST  cell  has  entered  its  command  loop,  it  can  accept  two  types  of  commands  - 
SET-VARI ABLE  and  LOOKUP,  with  the  obvious  semantics.  The  LOOKUP  command  is  used  by  VARIABLE 
cells: 

(DJFOBJECT  VARIABLE  (NAME)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

(TRANSMIT-WAIT  ENVIRONMENT 

(MAKE-COMMAND  'LOOKUP  CONTINUATION  NAME))) 

)) 

The  only  ottfeure  point  in  the  ALIST  command  loop  is  the  SET-VARIABLE  command's  returning  a  value. 
T  his  satisfies  the  contract  of  a  command  and  also  informs  any  caller  who  might  be  curious  that  the  setting  has 
been  completed  and  whether  it  succeeded.  One  cannot  set  or  look  up  a  variable  in  an  environment  in  which  it 
is  not  bound.  The  calls  to  FORMAT  would  not  carry  over  to  a  CM  implementation,  which  would  have  to  have 
its  own  ways  of  signalling  errors.  Support  for  error-handling  in  CM  languages  is  as  yet  poorly  understood. 
This  concludes  our  explanation  of  procedure  application  in  the  Cl.  I  Scheme  interpreter. 

SEQUENCE  and  PARALLEL  constructs  differ  only  in  their  attitude  toward  the  result  of  executing  the  first 
of  the  two  c  (pressions.  LHS  and  RHS.  (If  there  are  more  than  two  forms  in  a  SEQUENCE  or  PARALLEL  form, 
thcsvntaxcr  will  makcachain  ofSEQUENCE  or  PARALLEL  cells.)  A  SEQUENCE  must  set  upa  FORK  to  await 
the  completion  of  the  evaluation  of  llic  LHS  before  sending  the  EVALUATE  command  on  to  die  RHS.  A 
PARALLEL,  on  the  other  hand,  tells  die  LHS  to  send  its  result  to  a  bit  bucket  and  dicn  immediately  passes  the 
EVALUATE  ;ommand  to  the  RHS.  (Cl.l  does  not  support  bit  buckets  specially,  so  dicre  is  a  kind  of  cell  called 
BIT-BUCKfT  just  for  this  purpose.) 
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(DEFOBOECT  SEQUENCE  ( LHS  RHS)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

(TRANSMIT-WAIT  LHS 

(MAKE -COMMAND  ’EVALUATE 
(FORK  (RESULT-CHANNEL) 

(INPUT  RESULT-CHANNEL) 

(TRANSMIT-WAIT  RHS  COMMAND)) 

ENVIRONMENT))) 

)) 

(DEFOBJECT  PARALLEL  (LHS  RHS)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

( TRANSMI T- WAI T  LHS 

(MAKE-COMMAND  ’EVALUATE  (MAKE-BIT-BUCKET)  ENVIRONMENT)) 
(TRANSMIT-WAIT  RHS  COMMAND)) 

)) 

(DEFOBJECT  BIT-BUCKET  ()  (COMMAND)) 

Constants  arc  the  simplest  expressions  to  evaluate.  Upon  receiving  an  EVALUATE  message,  a  CONSTANT 
cell  simply  sends  its  constant  back  to  the  continuation: 

(DEFOBJECT  CONSTANT  (DATA)  (COMMAND) 

(DISPATCH  COMMAND 

((EVALUATE  CONTINUATION  ENVIRONMENT) 

(TRANSMIT  CONTINUATION  DATA)) 

)) 

All  that  remains  is  the  initialization  of  the  run-time  environment.  There  is  a  separate  cell  type  for  each 
primitive  the  language  supports,  and  these  arc  bound  to  the  appropriate  symbols  in  the  initial  environment. 
’ITic  initial  environment  is  set  to  the  Macl.isp  variable  GLOBAL -ENVIRONMENT  using  a  sequence  of  calk  to 
the  DEFINE  form  (which  was  created  by  (DEFCOMMAND  DEFINE  (FRAME  SYMBOL  EXPRESSION))): 

(DEFSTATE  INITIALIZE -GLOBAL -ENVIRONMENT  () 

(LET  ((GLOBAL  (MAKE-FRAME  NIL  NIL  NIL  NIL))) 

(SET  ’GLOBAL-ENVIRONMENT  GLOBAL) 

(DEFINE  GLOBAL  'CONS  (MAKE-PRIMITIVE-CONS-CLOSURE ) ) 

(DEFINE  GLOBAL  ’CAR  (MAKE -PRIMITIVE-CAR-CLOSURE ) ) 

(DEFINE  GLOBAL  ’CDR  (MAKE -PR IMITIVE-CDR- CLOSURE) ) 

(DEFINE  GLOBAL  EQ?  ( MAKE  -  PR 1M IT  I VE-EQ?- CLOSURE ) ) 

(DEFINE  GLOBAL  ’1+  (MAKE-PRIMITIVE- INCREMENT -CLOSURE ) ) 

(DEFINE  GLOBAL  ’1-  (MAKE -PRIMITIVE -DECREMENT-CLOSURE ) ) 

(DEFINE  GLOBAL  ’ZERO?  (MAKE -PRIMITIVE-ZEROP-CLOSURE ) ) 

(DEFINE  GLOBAL  ’+  (MAKE -PR1MITIVE-PLUS-CI  OSURE ) ) 

(DEFINE  GLOBAL  *  (MAKE -PRIMIT I VE -T 1MES-CLOSURE ) ) 

(DEFINE  GIOBAL  'LIST?  (MAKE -PRIMIT 1VE -L IS! P-CLOSURE ) ) 

(nrriNE  global  symbol?  (make  primitive-symbolp-closure)) 

(DEFINE  GLOBAL  'PRINC  (MAKE -PRIMITIVE -PR1NC-CL0SURE ) ) 

(DEFINE  GLOBAL  NIL  'NIL) 

(DEFINE  GIOBAL  ’T  *  T  ) ) ) 


Ilic  definitions  of  PRIMITIVE-CAR-CLOSURE  and  PfilMITIVE-CDR-CLOSURE  illustrate  two  different 
ways  of  writing  unary  primitives.  Kach  is  defined  using  DE FOBJECT  and  uses  an  ordinary  command  loop, 
and  each  forks  off  a  temporary  cell  to  wait  on  operand  evaluation.  1116  difference  is  that  while  the  fork 
created  by  PRIMITIVE-CAR-CLOSURE  waits  for  the  result  of  an  EVALUATE-FIRST  request  sent  to  the 
operand  list  by  the  closure,  the  fork  created  by  PR  IMIT I VE-CDR -CLOSURE  docs  all  of  the  work  itself: 


(Of  FOBJECT  PRIMITIVE-CAR-CLOSURE  ()  (COMMAND) 

(DISPATCH  COMMAND 

((EVLIS  CONTINUATION  OPERAND-LIST  OLD- ENVIRONMENT) 
(TRANSMIT-WAIT  OPERAND-LIST 
(MAKE-COMMAND  ’EVALUATE-FIRST 
(FORK  (RESULT-CHANNEL) 

(TRANSMIT-WAIT  (INPUT  RESULT-CHANNEL) 
(MAKE-COMMAND  ’GET-CAR  CONTINUATION))) 
OLD-ENVIRONMENT))) 


)) 


(01 FOBJECT  PR IMITIVE-CDR -CLOSURE  ()  (COMMAND) 

(DISPATCH  COMMAND 

((EVLIS  CONTINUATION  OPERAND-LIST  OLD- ENVIRONMENT) 

(MAKE-CELL  (KAPPA  () 

(TRANSMIT-WAIT  (EVALUATE-FIRST  OPERAND-LIST 

OLD-ENVIRONMENT) 

(MAKE-COMMAND  ’GET-CDR  CONTINUATION))))) 

)) 


T  he  asymmetry  is  for  only  expository  purposes;  each  definition  could  be  written  either  way.  The  other 
primitive  closures  arc  turned  out  by  macros  operating  on  these  models. 


Primitive  procedures  do  not  construct  alists.  but  rather  send  EVALUATE-FIRST  and  EVALUATE -SECOND 
commands  to  the  operand  lists  they  arc  given.  Ilic  DISPATCH  clauses  for  these  commands  were  omitted  in 
the  definition  of  OPERAND-CONS  given  above. 

(D( FOBJECT  OPERAND-CONS  (EXPRESSION  NEXT)  (COMMAND) 

(DISPATCH  COMMAND 

((BIND  CONTINUATION  PARAMETERS  ENVIRONMENT  NEXT-FRAME) 

•  ••) 

((EVALUATE-FIRST  CONTINUATION  ENVIRONMENT) 

(TRANSMIT-WAIT  EXPRESSION 

(MAKE-COMMAND  ’EVALUATE  CONTINUATION  ENVIRONMENT))) 

( (EVALUATE-SECOND  CONTINUATION  ENVIRONMENT) 

(1RANSMIT-WAIT  NEXT 

(MAKE-COMMAND  'EVALUATE-FIRST  CONTINUATION  ENVIRONMENT))) 

)) 

I  here  are  some  pieces  missing  from  the  present  implementation.  Were  we  to  develop  Scheme  into  a 
paullel  programming  language,  we  would  have  to  provide  facilities  lor  communication  between  programs. 
At  prevent.  1 1 Herein  Scheme  programs  that  are  running  in  parallel  can  communicate  only  through  a  shared 
global  emir  mntent.  and  there  are  no  facilities  for  reducing  the  contention  that  results  when  programs  share 
emironmen  s.  The  svnlaxer  is  an  artifact  of  the  (7  I  simulator's  Mad  isp  implementation  and  does  not 
addr  ess  the  issues  involved  in  huiUlme  real  I'M  linkers  and  loaders.  \Ne  have  not  thought  about  garbage 
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collcction. 

Almost  everything  we  learned  in  the  course  of  writing  the  interpreter  is  so  obvious  in  retrospect  as  to  be 
nearly  invisible.  (The  most  confusing  aspect  of  the  interpreter,  the  BIND  protocol,  arose  naturally  and  was 
confusing  only  in  retrospect.)  There  were  three  main  stages  in  the  program's  development: 

•  The  first  version  was  written  almost  entirely  in  terms  of  the  coding  cliches  described  in  the 
previous  section. 

•  The  second  version  introduced  the  FORKing  trick  described  in  the  context  of  CONDITIONAL  and 
so  implemented  the  tail-recursion  of  the  Scheme  interpreter  properly.  Various  optimi/ations  to  avoid 
unnecessary  wailing  by  cells  made  most  uses  of  the  DE  FCOMMAND  and  DE  FMAKER  cliches  disappear. 

•  The  third  version  made  DEFINE  expressions  work  properly  and  considerably  cleaned  up  the 
interpreter’s  modularity  by  changing  the  implementation  of  environments  from  a  simple  list  of  binding 
pairs  to  the  two-level  framc-and-alist  structure. 

We  have  used  the  Cl.l  Scheme  interpreter,  in  simulation,  to  run  some  substantial  Scheme  programs, 
including  a  simple  relational  database  system  (about  100  lines  of  code).  ’Ihc  main  thing  we  learned  from 
these  exercises  is  how  much  of  our  usual  programming  practice  assumes  a  serial  virtual  machine. 
Programming  in  Scheme  for  a  highly  parallel  virtual  machine,  we  found  that  efficiency  considerations  often 
differentiated  between  ways  of  writing  our  programs  that  were  equally  efficient  on  serial  machines.  Although 
our  programs  ran  correctly,  we  have  little  absolute  idea  how  quickly  they  would  be  executed  on  a  real  CM. 
On  the  basis  of  the  few  rough  calculations  we  can  perform,  we  guess  that  the  cross-over  point  between 
running  N  Scheme  programs  in  parallel  on  the  CM  and  in  serial  on  a  serial  mainframe  is  reached  with  N  in 
the  thousands. 

Some  Connection  Machine  efficiency  considerations 

A  working  programmer  constantly  makes  design  decisions  according  to  some  model  of  what  kinds  of 
processes  arc  efficient  or  inefficient  on  her  machine.  Our  ideas  about  how  to  design  CM  languages  and  write 
logically  correct  programs  in  them  arc  derived  from  bits  and  pieces  of  ideas  about  the  corresponding 
problems  on  serial  machines.  Nothing,  however,  has  prepared  us  to  reason  about  the  relative  efficiencies  of 
different  logically  correct  CM  programming  methods.  It’s  very  hard.  And  lacking  an  actual  CM.  we  have 
little  empirical  evidence  on  which  to  formulate  ideas  about  efficiency  considerations. 

On  one  analysis,  the  central  consideration  is  that  the  whole  machine  has  only  one  instruction  stream  and  so 
only  one  type  of  cell  can  be  running  during  any  given  wall-clock  tick.  T  o  a  first  approximation,  then,  in  a 
program  with  a  hundred  different  states  99  of  them  will  be  dormant  at  a  time.  But  because  the  CM's 
controller  is  free  to  run  the  states  in  any  order  it  likes,  this  can  be  a  poor  approximation  in  real  programs. 
Compile-time  and  run-time  analyses  can  determine  what  the  nmst  heavily  populated  slates  arc  likely  to  be  at  a 
given  time.  Since  semantics  of  CT  1  dictate  that  (he  outcome  of  a  program  is  independent  of  the  order  in 
which  the  states  are  run.  llie  Cl.l  programmer  can't  help  the  controller  out.  t  his  is  one  less  thing  for  the 
programmer  to  have  to  worry  about  and  one  less  opportunity  to  use  one's  understanding  of  what  happens 
when  in  designing  an  efficient  program. 

Such  considerations  might  be  entirely  irrelevant  if,  as  some  of  its  designers  expect,  the  CM  turns  out  to 
spend  almost  all  of  its  wall-clock  time  routing  messages.  In  that  case,  the  subtle  statistical  issues  of  router 
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congestion  vill  predominate  in  reasoning  about  efficiency.  If  the  programmer  can't  derive  or  intuit  any 
models  of  d  esc  matters  to  guide  her  efficiency  judgements,  she's  going  to  be  in  trouble. 

A  CM  p  -ogrammer  pays  not  for  die  total  amount  of  compulation  done  by  her  program  (as  on  a  serial 
machine)  but  for  the  number  of  different  things  that  must  be  done  on  each  step.  Consider,  for  example,  an 
algorithm  fc  r  locating  the  unique  element  of  a  linear  list  that  satisfies  some  complicated  predicate.  On  a  serial 
machine  it  is  best  to  test  each  element  of  the  list  in  turn,  proceeding  to  the  next  element  only  if  the  test  fails. 
On  the  CM  one  would  be  better  off  traversing  the  whole  list  putting  each  element  into  a  state  in  which  it  is 
about  to  apply  the  predicate.  Ihcn  all  of  the  predicate  tests  can  be  run  in  parallel.  Alternating  predicate-test 
and  ncxt-ckmcnt  operations  would  allow  only  one  predicate-test  to  be  executed  at  a  time. 

Another  important  consideration  in  CM  programming  is  that  one  often  pays  not  for  the  average  ease  of  an 
algorithm.  ;s  on  a  serial  machine,  but  for  the  worst  case.  Consider  an  algorithm  in  which  every  cell  in  the 
machine  goes  through  some  loop  until  some  calculation  converges.  Since  only  one  sort  of  thing  can  happen  at 
a  time,  the  c  ode  for  the  inside  of  the  loop  must  be  broadcast  repeatedly  until  all  one  million  cells'  loops  have 
converged.  If  a  cell  converges  it  must  sit  idle  until  all  its  siblings  have  converged  too. 

< 

We  hav<:  deliberately  avoided  discussing  die  more  traditional  considerations  of  SIMI)  machine 
programmitig,  many  of  which  concentrate  on  formulating  one's  algorithms  so  that  the  computation  is  as 
homogenous  as  possible,  'fhis  is  frequently  possible  in  applications  that  arc  governed  by  differential 
equations,  •  s  in  low-level  vision,  or  their  symbolic  analogs,  as  in  constraint  networks.  The  applications  in 
which  we  ar:  interested,  however,  generally  do  not  appear  to  enjoy  this  luxury. 

What  we  I  earned 

Because  we  had  little  a  priori  idea  of  what  would  make  a  good  Connection  Machine  programming 
language.  Cl.l  is  inevitably  little  more  than  a  minimal  extrapolation  from  the  archetypes  of  the  culture  of 
serial  machi  ic  programming.  Kxpcricncc  using  Cl.l  has  led  us  to  a  number  of  conclusions  as  to  what  the  next 
language  should  look  like. 

Cl.l  has  no  mechanisms  for  explicitly  assigning  a  type  to  a  cell.  Instead,  the  Cl.l  programmer  typically 
uses  the  bui  t-in  suite  mechanism  to  give  types  to  cells.  A  cell  is  considered  to  be  of  a  certain  type  just  in  ease 
its  suite  is  in  the  set  of  states  dial  implement  the  type.  A  difficulty  with  this  is  that  the  Cl.l  language  forces  all 
of  the  states  associated  with  a  certain  type  to  be  collected  into  one  place.  For  example,  consider  the  code  for 
the  CONS -BODE  cell  type  provided  above.  A  cell  placed  in  the  state  CONS -NODE  performs  the  usual 
handshake  with  its  owner  and  then  goes  into  an  infinite  loop  receiving  commands  and  responding  to  them. 
This  comm,  nd  loop  understands  two  types  of  commands.  GET -CAR  and  GET-CDR.  Ihc  cell  responds  by 
transmitting  the  requested  part  back  to  die  continuation  provided  in  the  command. 

Suppose  we  were  to  use  CONS  -  NODE  cells  to  store  a  list  of  items  in  the  conventional  I  isp  manner,  linking 
through  their  CDR-PARTs  a  series  ol'CONS-NODEs  whose  CAR -PARTs  arc  the  elements  of  the  list.  Given  die 
definition  move,  it  Uikcs  four  messages  to  retrieve  the  second  element  of  a  list:  two  commands  and  twq 
responses. 


C 


If  we  m  ulilv  the  definition  of  CONS  NODE  by  adding  a  new  "method"  (in  the  sense  of  current 
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objcct-oricntcd  programming  languages  [8, 16])  to  its  command-type  dispatch: 

(DISPATCH  COMMAND 

((GET-CADR  CONTINUATION) 

(TRANSMIT-WAIT  CDR-PART  (MAKE-COMMAND  ‘GET -CAR  CONTINUATION))) 

) 

then  we  can  obtain  the  second  element  of  a  list  in  only  three  messages:  a  command  of  type  GET-CADR  from 
the  requesting  cell  to  the  first  cons,  a  GET -CAR  command  from  the  first  cons  to  the  second,  and  a  third 
message  from  the  second  cons  back  to  the  requester. 

Having  to  modify  the  code  that  implements  the  CONS -NODE  type  whenever  a  new  operation  such  as 
GET-CADR  is  needed  is  a  severe  modularity  violation.  We  would  prefer  to  be  able  to  write  our  methods 
wherever  convenient,  potentially  in  lexically  distant  locations.  The  CM  compiler  could  achieve  this  by 
looking  through  the  program  and  collecting  together  each  set  of  related  methods  before  beginning 
compilation  of  the  lexical  context  in  which  they  all  must  appear.  But  this  is  only  a  shallow  solution  to  a  deep 
problem. 


To  see  why.  suppose  we  additionally  required  that  the  CL1  compiler  automatically  generate  additional 
methods  whenever  they  can  be  useful.  For  example,  the  GET-CADR  method  we  demonstrated  above  should 
ideally  be  generated  whenever  the  programmer  writes  something  like  (GET-CAR  (GET-CDR  ...))  in  her 
code:  an  analysis  of  the  message  passing  should  reveal  to  the  compiler  that  two  of  the  four  messages  involved 
can  be  compressed  into  a  single  message  directly  from  the  first  cons  to  the  second.  Such  optimizations  as  this 
require  the  compiler  to  consider  all  relevant  entities  simultaneously,  but  the  CM  compiler’s  view 
encompasses  only  one  cell  at  a  time.  We  would  like  the  compiler  to  maintain  a  compilc-timc  model  of  the 
joint  behavior  of  several  cells. 


This  requires  the  compiler  to  identify  situations  in  which  each  of  a  group  of  cells  is  in  a  known  suite.  It  can 
do  so  when,  for  example,  a  command  has  been  received  by  a  CONS-NODE  cell  from  a  particular  type  of 
edr-requesting  cell.  When  this  happens,  the  suite  of  both  cells  is  completely  determined:  the  requesting  cell 
must  be  waiting  for  a  reply  to  its  request,  and  the  cons  is  suiting  to  reply.  'Hie  compiler  would  now  be  free  to 
expand  its  viewpoint  to  include  both  cells,  if  only  the  language  allowed  the  user  to  tell  the  compiler  which 
suites  can  send  GET-CDR  commands  to  CONS-NODEs. 


A  related  shortcoming  dial  can  be  traced  to  CM 's  cellular  view  of  the  machine  is  the  excessive  amount  of 
code  devoted  to  message  handling  in  most  CM  programs.  Cl. Is  support  for  message  transmission  cannot  be 
made  significantly  more  powerful  because  message  transmission  is  a  non-local  phenomenon  and  CM 
maintains  only  a  local  model  of  the  machine's  behavior.  Because  the  code  implementing  our  communications 
protocols  was  often  spread  over  several  lexically  distant  locations,  we  found  it  difficult  to  define  ahstr.ictions 
for  them.  The  macros  wo  did  write  came  in  cooperating  sets:  DE  FMAKE  R.  DE  F OBJECT,  and  FORK  all  use  die 
OWNER  convention,  and  DEFCOMMAND  and  DEFOBJECT  both  use  die  command  channel  convention,  t  hese 
m. ktos  do  not  precisely  abstract  the  conventions  they  use  hut  rather  particular,  local,  wavs  of  using  them. 
When  we  revised  the  code  to  increase  parallelism  and  reduce  message  transmission,  the  macros  usually  failed 
to  capture  the  resulting  patterns. 


I'or  example,  when  the  initialization  of  a  cell  involved  more  than  the  OWNER  protocol.  DEFOBJECT  was  no 
longer  useful  (and  could  not  be  extended  to  be  useful).  Likewise,  macros  defined  with  DEFCOMMAND  failed 
in  die  presence  of  tail-recursion.  Kach  of  these  macros  expands  into  a  form  that  waits  on  a  result  and  returns 
it.  When,  as  in  the  evaluation  of  the  THEN  or  ELSE  expressions  of  a  CONDITIONAL,  we  intended  the  result 
from  a  com  nand  to  be  sent  not  to  the  originator  of  the  command  but  to  some  other  continuation,  we  had  to 
revert  to  constructing  the  command  explicitly. 

It  was  exactly  Cl.l's  relative  inability  to  allow  users  to  define  abstractions  of  message-passing  cliches  that 
defeated  an  attempt  to  implement  the  rule-based  language  Amord  [7]  in  CL1. 

Ycl  the  clearest  indication  of  the  underlying  problem  is  how  difficult  CL1  code  can  be  to  read.  When 
hand-simulating  the  execution  of  a  Cl.l  program,  one's  finger  must  jump  from  page  to  page,  following  chains 
of  causality  that  were  real  enough  to  the  programmer  but  arc  only  implicit  in  the  code.  This  is  graphically 
demonstrated  by  die  code  for  the  interface  between  OPERAND-CONScs  and  ALISTs,  in  which  no  indication  is 
given  as  to  which  TRANSMIT  corresponds  to  which  INPUT. 

These  symptoms  all  reflect  a  single  disorder.  TTicre  are  two  kinds  of  causality  vectors  in  CL1. 
state-transition  and  message-transmission,  but  Cl.l  explicitly  represents  only  the  first.  Because  of  this,  code 
must  be  grouped  inconveniently,  common  patterns  of  causality  are  difficult  to  abstracu  the  behavior  of  the 
code  is  hare  to  reason  about,  and  the  compiler  can  have  only  a  weak  model  of  the  computation.  For  the  sake 
of  bodi  the  user  and  the  compiler,  then,  a  programming  language  must  make  all  causality  expliciL 

We  arc  implementing  a  successor  to  CL1  that  docs  not  disdnguish  between  state-transition  and 
mcssagc-ira  ismission.  or  equivalently,  between  objects  and  messages.  By  unifying  these  two  kinds  of 
causality  into  a  single  construct  the  new  language,  called  CGI.  (for  Connection  Graph  language)  allows  all 
causality  to  be  made  explicit  This  proposal  realizes  the  duality  between  message  and  recipient  that  can  be 
seen  in  the  protocol  for  creating  and  chaining  together  new  AI.1ST  cells.  ITiat  protocol  can  be  described 
cidicr  as  a  collection  of  processes  passing  an  object  around,  or  as  a  single  process  moving  from  object  to 
object.  We  will  report  on  CGI.  in  [5). 

To  demt  nstratc  how  this  unification  can  relieve  some  of  the  problems  we  experienced,  consider  the 
breakdown  if  our  simple  macros  when  we  optimized  our  code.  The  way  in  which  our  proposal  addresses  this 
issue  can  best  be  understood  by  considering  an  analogy  between  a  CM  compiler  and  a  Scheme  compiler.  In 
[12|.  Steele  demonstrates  how  a  compiler  with  a  strong  understanding  of  die  simple  semantics  of  Scheme  can 
case  the  mat  to  writer's  task  by  reliably  optimizing  the  results  of  macroexpansion.  The  macro  writer  is  freed  to 
concentrate  on  the  semantics  of  the  macro.  We  want  macros  as  simple  as  those  defined  by  DE  FMESSAGE  and 
DEFOBJEC  to  express  communications  protocols  without  paying  a  runtime  penalty.  Thus  we  want  a  CM 
compiler  to  perform  the  kinds  of  optimizations  we  performed  by  hand  on  the  results  of  expanding  our  simple 
macros.  I  or  this  even  to  be  theoretically  possible  requires  that  the  compiler  have  a  non-local  model  of  die 
compulaliot :  for  it  to  be  reliable  and  efficient  requires  dint  that  model  be  simple.  We  hope  dial  our 
unification  of  stale-transition  and  message-transmission  will  play  die  role  dial  the  lambda  construct  plays  in 
Scheme. 

I  he  Cl  distinction  between  state-transition  and  message- transmission  was  derived  from  the  CM 
arvlniecliire  which  makes  exactly  that  distinction.  Ibis  correspondence  determines  an  obvious  assignment  of 


events  in  the  virtual  machine  to  events  in  the  physical  machine.  Once  we  unify  our  two  forms  of  causality,  the 
compiler  acquires  considerably  more  freedom  in  deciding  what  quantities  move  about  in  the  hardware  and 
which  stay  fixed  in  processor  cells.  Ihe  BIND  command,  for  example,  moved  four  quantities  in  its  fields 
down  a  chain  of  OPERAND-CONS  cells,  each  of  which  has  only  two  state  variables.  The  compiler  ought  to 
have  the  option  of  keeping  the  processes  embodied  by  propagation  of  BIND  commands  fixed  and  streaming 
chains  of  OPERAND-CONScs  over  them. 

Acknowledgements 

The  Connection  Machine  was  Danny  Hillis'  idea.  David  Chapman,  David  Christman,  Carl  Feynman, 
Brewster  Kahle,  Tom  Knight.  Bill  Kornfcld.  Glenn  Kramer,  Cliff  lesser,  Charles  l.ciscrson,  Henry 
Lieberman  Chris  Lindblad,  David  Moon,  Paul  Roscnblum,  Gerald  Sussman,  Jon  Taft  and  Richard  Zippcl 
have  all  contributed  to  our  understanding  of  the  problem  of  programming  Connection  Machines.  Some  of 
the  ideas  in  this  paper  arc  part  of  Connection  Machine  culture  and  should  be  credited  to  them.  Penny 
Berman  provided  important  comments  on  a  draft  of  this  paper. 


Bibliography 


1.  Abclson.  Harold,  and  Sussman.  Gerald  Jay.  course  notes  for  MIT  course  6.001, 
"Structure  and  Interpretation  of  Computer  Programs",  forthcoming. 

2.  Aho,  Alfred  V.,  and  Jeffrey  D.  UHman,  "Principles  of  Compiler  Design”, 

Addison*  Wesley  (1977). 

3.  Backus.  J..  "Can  Programming  be  Liberated  from  the  von  Neumann  Style?  A 
Functional  Style  and  its  Algebra  of  Programs",  Communications  of  the  ACM,  Vol. 
21  no.  8  (August  1978),  613-641. 

4.  Bawden,  Alan,  "CL1  Manual",  MIT  AI  Working  Paper  254  (Sept.  1983). 

5.  Bawden,  Alan,  "A  Programming  Language  for  Massively  Parallel  Computers",  MS 
Thesis,  Dept,  of  Electrical  Engineering  and  Computer  Science,  MIT,  September 
1984. 

6.  Christman,  David  P.,  "Programming  the  Connection  Machine",  MS  Thesis,  Dept 
of  Electrical  Engineering  and  Computer  Science,  MIT,  January  1984. 

7.  de  Klecr,  Johan,  Jon  Doyle,  Charles  Rich,  Guy  L  Steele  Jr,  and  Gerald  Jay 
Sussman,  "AMORD:  A  Deductive  Procedure  System",  MIT  AI  Memo  435  (Jan. 
1978). 

8.  Goldberg,  Adclc,  and  David  Robson,  ”Smalltalk-80:  The  Language  and  its 
Implementation",  Addison- Wesley  (1983). 

9.  Guzman.  Adolfo,  Miguel  Gcrzso,  Kcmer  B.  Norkin,  S.  Y.  Vilenkin,  "The 
Conversion  via  Software  of  a  SIMD  Processor  into  a  MIMD  Processor",  Proc.  IEEE 
Workshop  on  Computer  Architecture  for  Pattern  Analysis  and  Image  Database 
Management,  Oct.  1983. 

10.  Hewitt,  Carl,  "Viewing  control  structures  as  patterns  of  passing  messages",  AI 
Journal.  Vol.  8  no.  3  (June  1977),  323-363. 

11.  Hillis,  W.  Daniel,  "  Ihc  Connection  Machine  (Computer  Architecture  for  the  New 
Wave)",  MIT  AI  Memo  646  (Sept.  1981). 


12. 


Steele.  Guy  I  ewisJr..  "RABBI  T:  A  Compiler  lor  SCHEME  (A  Study  in  Compiler 
Optimization)”,  MU  AI- I  K-474  (May  1978). 


-25- 


13.  Stcclc,  Guy  Lewis  Jr.,  and  Gerald  Jay  Sussman,  "LAMBDA:  The  Ultimate 
Imperative",  MIT  A1  Memo  353  (March  1976). 

14.  Steele.  Guy  Lewis  Jr.,  and  Gerald  Jay  Sussman,  "The  Revised  Report  on  SCHF.ME 
A  Dialect  of  Lisp",  MIT  A!  Memo  452  (Jan.  1978). 

15.  Sussman,  Gerald  Jay,  and  Guy  Lewis  Stcclc  Jr.,  "The  Art  of  the  Interpreter  or.  The 
Modularity  Complex”,  MIT  Al  Memo  453  (May  1978). 

16.  Weinreb,  Daniel,  and  David  Moon,  "Lisp  Machine  Manual",  Symbolics  Inc.  (July 
1981). 


Stcclc,  Guy  Lewis  Jr.,  and  Gerald  Jay  Sussman,  "LAMBDA:  The  Ultimate 
Imperative",  MIT  AI  Memo  353  (March  1976). 

Steele.  Guy  Lewis  Jr.,  and  Gerald  Jay  Sussman,  "The  Revised  Report  on  SCHEME 
A  Dialect  of  Lisp",  MIT  AI  Memo  452  (Jan.  1978). 

Sussman,  Gerald  Jay,  and  Guy  Lewis  Steele  Jr.,  "The  Art  of  the  Interpreter  or.  The 
Modularity  Complex",  MIT  AI  Memo  453  (May  1978). 

Weinreb,  Daniel,  and  David  Moon,  "Lisp  Machine  Manual",  Symbolics  Inc.  (July 
1981). 


